A note on exact algorithms for the identical parallel machine scheduling problem

A recently published paper by E. Mokotoff presents an exact algorithm for the classical P ||Cmax scheduling problem, evaluating its average performance through computational experiments on a series of randomly generated test problems. It is shown that, on the same types of instances, an exact algorithm proposed 10 years ago by the authors of the present note outperforms the new algorithm by some orders of magnitude. Given n jobs with associated processing times p1, . . . , pn, and m parallel identical machines, each of which can process at most one job at time, the Parallel Machine Scheduling Problem is to assign each job to exactly one machine so that the maximum completion time of a job (makespan) is minimized. Using the three-field classification introduced in Graham, Lawler, Lenstra and Rinnooy Kan [3], the problem is denoted in the scheduling literature as P ||Cmax. We assume, as is usual, that the processing times are positive integers and that 1 < m < n. The problem is known to be NP-hard in the strong sense (see Garey and Johnson [2]). In a recently published paper, Mokotoff [4] presented a cutting plane algorithm for its exact solution, based on iterated addition of valid inequalities to the ILP model, and solution of the LP relaxation of the resulting problem. In an older paper, Dell’Amico and Martello [1] had presented a branch-and-bound algorithm for the same problem, based on sophisticated lower and upper bound computations and the use of dominance criteria. The algorithm by Mokotoff [4] has been implemented by the author using the simplex and branch-and-bound methods included in the CPLEX 5.6 callable library. It has been computationally tested, on a Pentium 500, on three classes of random instances obtained by uniformly generating the pi values in the ranges [1, 100], [10, 100] and [50, 100], for various instance sizes. We executed the C implementation of the Dell’Amico and Martello [1] algorithm on instances generated in the same way. As we could not find a Pentium 500, we used a slightly slower Celeron 434 MHz. Table 1 compares, on small-size instances, our